home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1994 March / Internet Info CD-ROM (Walnut Creek) (March 1994).iso / inet / internet-drafts / cyn < prev    next >
Encoding:
Internet Message Format  |  1993-06-11  |  15.9 KB
  1. Received: from mail.bellcore.com by IETF.CNRI.Reston.VA.US id aa10958;
  2.           11 Jun 93 14:00 EDT
  3. Received: from eve (eve.bellcore.com) by mail.bellcore.com (5.65c/2.1)
  4.     id AA12091; Fri, 11 Jun 1993 13:57:15 -0400
  5. Return-Path: <dave@mail.bellcore.com>
  6. Received: by eve (4.1/4.7)
  7.     id AA24356; Fri, 11 Jun 93 14:01:49 EDT
  8. Date: Fri, 11 Jun 93 14:01:49 EDT
  9. From: Dave Piscitello <dave@mail.bellcore.com>
  10. X-Station-Sent-From: eve.bellcore.com
  11. Message-Id: <9306111801.AA24356@eve>
  12. To: internet-drafts@IETF.CNRI.Reston.VA.US
  13. Subject: revised i-d
  14. Cc: pjs1@eve.bellcore.com
  15.  
  16.  
  17. Please post the following revision to draft-tuba-sysids-01.txt
  18. as -02.txt. Thanks in advance for your help.
  19.  
  20. --------
  21.  
  22. IETF                               Page 1
  23. May 27, 1993       System Identifiers for TUBA     Internet Draft
  24.  
  25.  
  26.       Assignment of System Identifiers for TUBA/CLNP Hosts
  27.  
  28.  
  29.                  David M. Piscitello
  30.                            Bellcore
  31.                   dave@sabre.bellcore.com
  32.  
  33.  
  34.                        Status of this Memo
  35.  
  36. This document is an Internet Draft.  Internet Drafts are working
  37. documents of the Internet Engineering Task Force (IETF), its
  38. Areas, and its Working Groups. Note that other groups may also
  39. distribute working documents as Internet Drafts.
  40.  
  41. Internet Drafts are draft documents valid for a maximum of six
  42. months. Internet Drafts may be updated, replaced, or obsoleted by
  43. other documents at any time.  It is not appropriate to use
  44. Internet Drafts as reference material or to cite them other than
  45. as a "working draft" or "work in progress."
  46.  
  47. Please check the Internet Draft abstract listing contained in the
  48. IETF Shadow Directories (cd internet-drafts) to learn the current
  49. status of this or any other Internet Draft.
  50.  
  51.  
  52.                           Introduction
  53.  
  54. This Internet-Draft specifies methods for assigning a 6 octet
  55. system identifier portion of the OSI NSAP address formats
  56. described in "Guidelines for OSI NSAP Allocation in the Internet"
  57. (RFC1237, 1991), in a fashion that ensures that the ID is unique
  58. within a routing domain. It also recommends methods for assigning
  59. system identifiers having lengths other than 6 octets. The 6
  60. octet system identifiers recommended in this Internet-Draft are
  61. assigned from 2 globally administered spaces (IEEE 802 or
  62. "Ethernet", and IP numbers, administered by the Internet Assigned
  63. Numbers Authority, IANA).
  64.  
  65. At this time, the primary purpose for assuring uniqueness of
  66. system identifiers is to aid in autoconfiguration of NSAP
  67. addresses in TUBA/CLNP internets (RFC1347, 1992). The guidelines
  68. in this paper also establish an initial framework within which
  69. globally unique system identifiers, also called endpoint
  70. identifiers, may be assigned.
  71.  
  72.  
  73.                             Abstract
  74.  
  75. This document describes conventions whereby the system identifier
  76. portion of an RFC1237 style NSAP address may be guaranteed
  77. uniqueness within a routing domain for the purpose of
  78. autoconfiguration in TUBA/CLNP internets. The mechanism is
  79.  
  80.  
  81.  
  82.  
  83.  
  84.  
  85.  
  86.  
  87.  
  88. IETF                               Page 2
  89. Internet Draft     System Identifiers for TUBA       May 27, 1993
  90.  
  91.  
  92. extensible and can provide a basis for assigning system
  93. identifiers in a globally unique fashion.
  94.  
  95.  
  96.                          Acknowledgments
  97.  
  98. Many thanks to Radia Perlman of Digital Equipment and Ross Callon
  99. of Wellfleet Communications for their insights and assistance.
  100. Thanks also to the Ethernet connector to my MAC, which
  101. conveniently and quite inobtrusively fell out, enabling me to get
  102. an entire day's worth of work done without email interruptions.
  103.  
  104.  
  105. 1.  Background
  106.  
  107. The general format of OSI network service access point (NSAP)
  108. addresses is illustrated in Figure 1.
  109.  
  110.           _______________________________________________
  111.           |____IDP_____|_______________DSP______________|
  112.           |__AFI_|_IDI_|_____HO-DSP______|___ID___|_SEL_|
  113.  
  114.                 IDP     Initial Domain Part
  115.                 AFI     Authority and Format Identifier
  116.                 IDI     Initial Domain Identifier
  117.                 DSP     Domain Specific Part
  118.                 HO-DSP  High-order DSP
  119.                 ID      System Identifier
  120.                 SEL     NSAP Selector
  121.  
  122.                 Figure 1: OSI NSAP Address Structure.
  123.  
  124. The recommended encoding and allocation of NSAP addresses in the
  125. Internet is specified in RFC 1237. RFC 1237 makes the following
  126. statements regarding the system identifier (ID) field of the
  127. NSAPA:
  128.  
  129.   1.  the ID field may be from one to eight octets in length
  130.  
  131.   2.  the ID must have a single known length in any particular
  132.       routing domain
  133.  
  134.   3.  the ID field must be unique within an area for ESs and
  135.       level 1 ISs, and unique within the routing domain for level
  136.       2 ISs.
  137.  
  138.   4.  the ID field is assumed to be flat
  139.  
  140. RFC1237 further indicates that, within a routing domain that
  141. conforms to the OSI intradomain routing protocol (ISO 10589,
  142. 1992) the lower-order octets of the NSAP should be structured as
  143. the ID and SEL fields shown in Figure 1 to take full advantage of
  144. intradomain IS-IS routing. (End systems with addresses which do
  145.  
  146.  
  147.  
  148.  
  149.  
  150.  
  151.  
  152.  
  153.  
  154. IETF                               Page 3
  155. May 27, 1993       System Identifiers for TUBA     Internet Draft
  156.  
  157.  
  158. not conform may require additional manual configuration and be
  159. subject to inferior routing performance.)
  160.  
  161. Both GOSIP Version 2 (under DFI-80h, see Figure 2a) and ANSI DCC
  162. NSAP addressing (Figure 2b) define a common DSP structure in
  163. which the system identifier is assumed to be a fixed length of 6
  164. octets.
  165.  
  166.                _______________
  167.                |<--__IDP_-->_|___________________________________
  168.                |AFI_|__IDI___|___________<--_DSP_-->____________|
  169.                |_47_|__0005__|DFI_|AA_|Rsvd_|_RD_|Area_|ID_|Sel_|
  170.         octets |_1__|___2____|_1__|_3_|__2__|_2__|_2___|_6_|_1__|
  171.  
  172.                     Figure 2 (a): GOSIP Version 2 NSAP structure.
  173.                ______________
  174.                |<--_IDP_-->_|_____________________________________
  175.                |AFI_|__IDI__|____________<--_DSP_-->_____________|
  176.                |_39_|__840__|DFI_|_ORG_|Rsvd_|RD_|Area_|_ID_|Sel_|
  177.         octets |_1__|___2___|_1__|__3__|_2___|_2_|__2__|_6__|_1__|
  178.  
  179.                      IDP   Initial Domain Part
  180.                      AFI   Authority and Format Identifier
  181.                      IDI   Initial Domain Identifier
  182.                      DSP   Domain Specific Part
  183.                      DFI   DSP Format Identifier
  184.                      ORG   Organization Name (numeric form)
  185.                      Rsvd  Reserved
  186.                      RD    Routing Domain Identifier
  187.                      Area  Area Identifier
  188.                      ID    System Identifier
  189.                      SEL   NSAP Selector
  190.  
  191.                  Figure 2(b): ANSI NSAP address format for DCC=840
  192.  
  193.  
  194. 2.  Autoconfiguration
  195.  
  196. There are provisions in OSI for the autoconfiguration of area
  197. addresses. OSI end systems may learn their area addresses
  198. automatically by observing area address identified in the IS-
  199. Hello packets transmitted by routers using the ISO 9542 End
  200. System to Intermediate System Routing Protocol, and may then
  201. insert their own system identifier. (In particular, RFC 1237
  202. explains that when the ID portion of the address is assigned
  203. using IEEE style 48-bit identifiers, an end system can
  204. reconfigure its entire NSAP address automatically without the
  205. need for manual intervention.) End systems that have not been
  206. pre-configured with an NSAPA may also request an address from an
  207. intermediate system their area using (ISO 9542/DAM1, 1992).
  208.  
  209.  
  210.  
  211.  
  212.  
  213.  
  214.  
  215.  
  216.  
  217.  
  218.  
  219.  
  220. IETF                               Page 4
  221. Internet Draft     System Identifiers for TUBA       May 27, 1993
  222.  
  223.  
  224. 2.1  Autoconfiguration and 48-bit addresses
  225.  
  226. There is a general misassumption that the 6-octet system
  227. identifier must be a 48-bit IEEE assigned (ethernet) address.
  228. Generally speaking, autoconfiguration does not rely on the use of
  229. a 48-bit ethernet style address; any system identifier that is
  230. globally administered and is unique will do. The use of 48-bit/6
  231. octet system identifiers is "convenient...because it is the same
  232. length as an 802 address", but more importantly, choice of a
  233. single, uniform ID length allows for "efficient packet
  234. forwarding", since routers won't have to make on the fly
  235. decisions about ID length (see Perlman, 1992, pages 156-157).
  236. Still, it is not a requirement that system identifiers be 6
  237. octets to operate the the IS-IS protocol, and IS-IS allows for
  238. the use of IDs with lengths from 1 to 8 octets.
  239.  
  240.  
  241. 3.  System Identifiers for TUBA/CLNP
  242.  
  243. Autoconfiguration is a desirable feature for TUBA/CLNP, and is
  244. viewed by some as "essential if a network is to scale to a truly
  245. large size" (Perlman, 1992).
  246.  
  247. For this purpose, and to accommodate communities who do not wish
  248. to use ethernet style addresses, a generalized format that
  249. satisfies the following criteria is desired:
  250.  
  251.    o+ the format is compatible with installed end systems
  252.      complying to RFC 1237
  253.  
  254.    o+ the format accommodates 6 octet, globally unique system
  255.      identifiers that do not come from the ethernet address space
  256.  
  257.    o+ the format accommodates globally unique system identifiers
  258.      having lengths other than 6 octets
  259.  
  260. The format and encoding of a globally unique system identifier
  261. that meets these requirements is illustrated in Figure 3:
  262.  
  263.  
  264.    Octet 1     Octet 2     Octet 3 ...     Octet LLL-1  Octet LLLL
  265. +-----------+-----------+-----------+- ...-+-----------+-----------+
  266. | xxxx TTQQ | xxxx xxxx | xxxx xxxx |      | xxxx xxxx | xxxx xxxx |
  267. +-----------+-----------+-----------+- ...-+-----------+-----------+
  268.  
  269.                 Figure 3. General format of the system identifier
  270.  
  271. 3.1  IEEE 802 Form of System Identifier
  272.  
  273. The format is compatible with globally assigned IEEE 802
  274. addresses.  Octet 1 identifies a 2 bit qualifier (QQ) and an
  275. optional subtype (TT) whose semantics are associated with the
  276. qualifier.  If the qualifier QQ equals 00 or 01, there is no
  277.  
  278.  
  279.  
  280.  
  281.  
  282.  
  283.  
  284.  
  285.  
  286. IETF                               Page 5
  287. May 27, 1993       System Identifiers for TUBA     Internet Draft
  288.  
  289.  
  290. subtype (I told you it was optional); the system identifier is
  291. interpreted as a 48-bit, globally unique identifier assigned from
  292. the IEEE 802 committee (an ethernet address). The remaining bits
  293. in octet 1, together with octets 2 and 3 are the vendor code or
  294. OUI (organizationally unique identifier), as illustrated in
  295. Figure 4. The ID is encoded in IEEE 802 canonical form.
  296.  
  297.  
  298.    Octet 1     Octet 2     Octet 3     Octet 4     Octet 5   Octet 6
  299. +-----------+-----------+-----------+-----------+-----------+-----------+
  300. | VVVV VV00 | VVVV VVVV | VVVV VVVV | SSSS SSSS | SSSS SSSS | SSSS SSSS |
  301. +-----------+-----------+-----------+-----------+-----------+-----------+
  302.  
  303. |------------vendor code -----------|--------station code---------------|
  304.  
  305.                 Figure 4. IEEE 802 form of system identifier
  306.  
  307.  
  308. 4.  Embedded IP Address as System Identifier
  309.  
  310. If qualifer QQ = 10, the subtype (TT) bits in Figure 3 are
  311. relevant.  If the subtype (TT) = 00, then the length of the
  312. system identifier is 48-bits/6 octets. The remaining nibble in
  313. octet 1 is set to zero.  Octet 2 is reserved and has a pre-
  314. assigned value (see Figure 5).  Octets 3 through 6 contain a
  315. valid IP address, assigned by IANA.  Each octet of the IP address
  316. is encoded in binary, in internet canonical form, i.e., the
  317. leftmost bit of the network number first.
  318.  
  319.  
  320.    Octet 1     Octet 2     Octet 3     Octet 4     Octet 5   Octet 6
  321. +-----------+-----------+-----------+-----------+-----------+-----------+
  322. | 0000 0010 | 1010 1010 | aaaa aaaa | bbbb bbbb | cccc cccc | dddd dddd |
  323. +-----------+-----------+-----------+-----------+-----------+-----------+
  324.  
  325. |-len&Type--|--reserved-|---------IP address----------------------------|
  326.  
  327.                 Figure 5. Embedded IP address as system identifier
  328.  
  329. As an example, the host "eve.bellcore.com = 128.96.90.55" could
  330. retain its IP address as a system identifier in a TUBA/CLNP
  331. network. The encoded ID is illustrated in Figure 6.
  332.  
  333.  
  334.    Octet 1     Octet 2     Octet 3     Octet 4     Octet 5   Octet 6
  335. +-----------+-----------+-----------+-----------+-----------+-----------+
  336. | 0000 0010 | 1010 1010 | 1000 0000 | 0110 0000 | 0101 1010 | 0011 0111 |
  337. +-----------+-----------+-----------+-----------+-----------+-----------+
  338.  
  339. |-len&Type--|--reserved-|---------IP address----------------------------|
  340.  
  341.                 Figure 6. Example of IP address encoded as ID
  342.  
  343.  
  344.  
  345.  
  346.  
  347.  
  348.  
  349.  
  350.  
  351.  
  352. IETF                               Page 6
  353. Internet Draft     System Identifiers for TUBA       May 27, 1993
  354.  
  355.  
  356. H 2 "Other forms of System Identifiers"
  357.  
  358. To allow for the future definition of additional 6-octet system
  359. identifiers, the remaining qualifier/subtype values are reserved.
  360.  
  361. It is also possible to identify system identifiers with lengths
  362. other than 6 octets. Communities who wish to use 8 octet
  363. identifiers (for example, embedded E.164 international numbers
  364. for the ISDN ERA) must use a GOSIP/ANSI DSP format that allows
  365. for the specification of 2 additional octets in the ID field,
  366. perhaps at the expense of the "Rsvd" fields; this document
  367. recommends that a separate Domain Format Indicator value be
  368. assigned for such purposes; i.e., a DFI value that is interpreted
  369. as saying, among other things, "the system identifier encoded in
  370. this DSP is 64-bits/8 octets. The resulting ANSI/GOSIP DSP
  371. formats under such circumstances are illustrated in Figure 7:
  372.  
  373.                ______________
  374.                |<--_IDP_-->_|______________________________
  375.                |AFI_|__IDI__|____________<--_DSP_-->_______|
  376.                |_39_|__840__|DFI_|_ORG_|RD_|Area_|_ID_|Sel_|
  377.         octets |_1__|___2___|_1__|__3__|_2_|__2__|_8__|_1__|
  378.  
  379.         Figure 7a: ANSI NSAP address format for DCC=840, DFI=foo
  380.  
  381.                _______________
  382.                |<--__IDP_-->_|___________________________________
  383.                |AFI_|__IDI___|___________<--_DSP_-->____________|
  384.                |_47_|__0005__|DFI_|AA_|_RD_|Area_|ID_|Sel_|
  385.         octets |_1__|___2____|_1__|_3_|_2__|_2___|_8_|_1__|
  386.  
  387.                       IDP   Initial Domain Part
  388.                       AFI   Authority and Format Identifier
  389.                       IDI   Initial Domain Identifier
  390.                       DSP   Domain Specific Part
  391.                       DFI   DSP Format Identifier
  392.                       AA    Administrative Authority
  393.                       RD    Routing Domain Identifier
  394.                       Area  Area Identifier
  395.                       ID    System Identifier
  396.                       SEL   NSAP Selector
  397.  
  398.        Figure 7b: GOSIP Version 2 NSAP structure, DFI=bar
  399.  
  400. Similar address engineering can be applied for those communities
  401. who wish to have shorter system identifiers; have another DFI
  402. assigned, and expand the reserved field.
  403.  
  404.  
  405.  
  406.  
  407.  
  408.  
  409.  
  410.  
  411.  
  412.  
  413.  
  414.  
  415.  
  416.  
  417.  
  418. IETF                               Page 7
  419. May 27, 1993       System Identifiers for TUBA     Internet Draft
  420.  
  421.  
  422. 5.  Conclusions
  423.  
  424. This proposal should debunk the "if it's 48-bits, it's gotta be
  425. an ethernet address" myth. It demonstrates how IP addresses may
  426. be encoded within the 48-bit system identifier field in a
  427. compatible fashion with IEEE 802 addresses, and offers guidelines
  428. for those who wish to use system identifiers other than those
  429. enumerated here.
  430.  
  431.  
  432. 6.  References
  433.  
  434. RFC1237.        Callon, R., Gardner, E., and Colella, R. "Guidelines
  435.                 for OSI NSAP Allocation in the Internet", June 1991.
  436.  
  437. RFC1347.        Callon, R., "TCP/UDP over Big Addresses (TUBA)", May 1992.
  438.  
  439. ISO 10589.      ISO, Intradomain routing protocol for use in conjunction with
  440.                 ISO 8473, Protocol for providing the OSI connectionless
  441.                 network service.
  442.  
  443. ISO 9542.       ISO, End-system and intermediate-system routing protocol
  444.                 for use in conjunction with ISO 8473, Protocol for
  445.                 providing the OSI connectionless network service.
  446.  
  447. ISO 9542/DAM1.  ISO, End-system and intermediate-system routing protocol
  448.                 for use in conjunction with ISO 8473, Protocol for
  449.                 providing the OSI connectionless network service.
  450.                 Amendment 1: Dynamic Discovery of OSI NSAP Addresses
  451.                 End Systems.
  452.  
  453. Perlman         Perlman, Radia., Interconnections: Bridges and Routers,
  454.                 Addison-Wesley Publishers, Reading, MA. 1992.
  455.  
  456.  
  457. 7.  Author Information
  458.  
  459. David M. Piscitello
  460. Bell Communications Research
  461. NVC 1C322
  462. 331 Newman Springs Road
  463. Red Bank, NJ 07701
  464. dave@mail.bellcore.com
  465.  
  466.  
  467.  
  468.  
  469.  
  470.  
  471.  
  472.  
  473.  
  474.  
  475.  
  476.  
  477.  
  478.  
  479.  
  480.  
  481.  
  482.  
  483.